1. Field of the Invention
This invention relates to the evaluation of security policies within a computing system, and particularly to the evaluation of security policies and the creation of new security policies within a computing system.
2. Description of Background
Before our invention computing system frameworks, such as Java™ and Microsoft™.NET Common language Runtime (CLR) were considered to be sophisticated enough to allow for the specification of complex and fine-grained security policies. Typically, these security policies included the ability to specify the access rights that were required to be granted to code and to the subjects (users and/or services) running the code. In regard to implemented security policies two fundamental rules must be respected: First, the access rights granted to code and subjects must have been sufficient to run the code (otherwise there will be authorization failures at run time, which may make an application unstable), and secondly, none of the access rights granted to code and subjects must be unnecessary or redundant; this aspect being required to avoid violating the Principle of Least Privilege.
However, given the complexity of modern, fine-grained computing systems, defining an access policy based on the requirements of the code is very difficult, if not impossible. Defining an access policy may require the procedure of manually inspecting the code, understanding what permissions the code requires, and detecting which portions of code are going to be executed under the authority of subjects. Moreover, a policy should grant the permissions required by the code to either the code or the subjects executing the code (ideally not to both, as this would be a violation of the Principle of Least Privilege). On the other hand, if a policy has already been defined, evaluating it requires, as mentioned above, inspecting the code, understanding what permissions the code requires, detecting which portions of code are going to be executed under the authority of subjects. Further, the permissions the current policy grants to the code and the subjects executing the code must be identified and the following must be verified:                1. The code and/or the subjects executing the code have been granted enough permissions so that the application can execute without authorization failures (this aspect can create exploitable run-time problems), as long as the code and/or the subjects are trusted enough to be granted those permissions, and        2. The code and/or the subjects executing the code have not been granted unnecessary or overlapping permissions (which would constitute a violation of the Principle of Least Privilege).        
Policy defining procedures are further complicated by the fact that permissions granted to a subject are obtained as the union of the permissions that have been granted to the subject's authenticated principals. Therefore, it is necessary to detect for each subject what permissions its authenticated principal have been granted. Performing manual code and security-policy inspection to define a new security policy or evaluate an existing one is a tedious, error prone, and time consuming procedure. Dynamic analysis or testing is another approach typically undertaken to solve authorization problems. However, in the absence of a complete suite of test eases, this approach is not guaranteed to detect all the authorization requirements of a program, and further, unexpected run-time authorization failures can arise.
Therefore there exists a need for a methodology for combining policy analysis and static analysis of code in order to compute whether the permissions granted, by the policy to code and to the subjects executing the code are appropriate. Further, this need extends to the implementation of a methodology for verifying that too many permissions have not been granted (otherwise, this would be a violations of the Principle of Least Privilege), and that the permissions being granted are sufficient to execute the code without run-time authorization failures (in this instance the program will not execute).